ZAR 8.4 Online Manual

Be sure to read the Before Starting Checklist before attempting recovery.

ZAR general execution flow
  • Main window layout
  • Introduction panel
  • Task types
  • Physical device selection
  • Partition selection
    • Scan for missing volumes
    • Manual volume definition
  • Analysis run
  • File explorer
  • File copying
  • Completion

Digital image recovery
  • Image recovery

RAID reconstruction
  • Configuring RAID recovery
    • Defining a RAID manually
  • RAID reconstruction process

Direct disk viewing with ZAR
  • Disk Viewer overview
  • Disk navigation
  • Virtual volumes
  • Supported formats
  • Search for text

Advanced configuration options
  • Configuring general options
  • Physical drive and partition options
  • Options common to all filsystems
  • NTFS reconstruction options
  • S.M.A.R.T. options
  • RAID reconstruction options
  • Validation options

Miscellaneous information
  • S.M.A.R.T. basics
  • Save files
  • Data validation
  • Stats reporting
    • Stats privacy
  • Using wildcards
  • Known file formats


General data recovery procedure

Step 1 - Initial size-up
The following information should be gathered and evaluated as soon as possible after discovering a data loss, preferably before starting any actions.
  • Possible cause(s) of the failure.
  • Number, size, and location (which physical disk(s) contains the volume?) of the affected volume(s).
  • Number, size and location (on which controller/channel?) of the affected physical drive(s), if any.
  • Overall host machine condition (memory functional? RAID controller(s) functional? any degraded but mountable RAID(s) need backing up immediately). This is needed to determine if it is feasible to continue recovery on the same machine, or the affected device(s) should be attached to some other (known-good) system.
  • Approximate amount (size; number of files), file types and importance of the data lost.
  • Availability and state of the backup copies of that data, if any.

Based on the size-up results, we typically assign two "scores" to each case, each based on the binary scale:

  • Understanding of the situation, which can be either "clear" or "unclear". It is often counterproductive to troubleshoot an "unclear" situation. Reasonable allocation of effort would be to continue gathering information until eventually everything becomes "clear".
  • Damage severity (how valuable the data is? are there any backups?), either "minor" or "major". This has little effect on the recovery process (since all the procedures do not differentiate between valuable and replaceable information), but provides some timeframe/budget constraints.

Step 2 - Evaluation of available resources
Sometimes you will need to utilize all the resources available to achieve a successful recovery. This includes both human and hardware resources.
  • If there is a local computer expert available, you may want give him a call and ask for assistance or for a cross-check. You should specifically ask him to cross-check the information collected during previous step.
  • Check if you have some "spare" computer(s) available (if the original machine is for some reason unstable, you will need to connect hard drive(s) to that "spare" machine).
  • Check if there is plenty of disk space available to hold the data recovered. We found two approximations useful: a). half the size of the damaged volume, and b). twice the size of the data you're going to recover. When planning, keep in mind you will most likely need the largest of the two.

Step 3 - Setting up
Never install any software (incl. data recovery software) on the damaged disk. Generally, no writes to the damaged drive should be allowed.

Second important thing at this point is to decide what hardware reconfiguration is required. Typical scenarios are outlined below:

  • Most widely used approach is to get the failed drive out of its host machine and put it into some known-working system. Additional (good) hard disk(s) might be needed depending on a free space availability.
  • If there were more than one drive in the failed system and the system is still reasonably operational it may be possible (subject to free space requirements) to perform recovery without any hardware reconfiguration.
  • If there is some special controller involved (e.g. RAID controller, or a SATA controller), it may be required to relocate the controller along with the damaged hard disk(s).

Whatever method is chosen, the following points should be considered:

  • Ensure adequate power supply.
  • Double check proper cabling, (SCSI) termination, and jumper setup.
  • For IDE drives, check proper addressing mode (LBA vs. CHS/LARGE) configuration in BIOS.
  • Ensure adequate cooling (ambient temperature higher than 25 deg C? any physical malfunction identified/suspected?); install additional fans if deemed necessary.

Step 4 - Recovery run
No significant problems should arise during the recovery run if previous steps worked out properly. Install our software onto the host machine and run it. Never install any kind of the software onto the damaged volume(s). Check a list of things to consider.
  • If the machine performing recovery freezes at some point, check its memory (using some memory testing tool like GoldMemory). If memory turns out good, disk and/or bus controller(s) may be at fault (older-generation Promise controllers/drivers are known to lock up under load - check IRQ sharing).

Step 5 - Evaluation of the results
Once the recovery is done, make sure you review the most important files manually. The automated process cannot distinguish between meaningful data and structured nonsense. There is no substitute for a manual review.

Step 6 - Cleaning up
  • Take care when rolling back any hardware changes you have made.
  • Physically malfunctioned drives should not be placed back into the production environment. Replace them under warranty. There are few alternative uses of the physically damaged hard drive - we use them as a large (say, 40GB) floppy disk to transfer large amounts of data machine-to-machine, but special precautions should be taken to ensure that the backup copy of the data on the unstable drive is always readily available.

Important note: Although sometimes pretty specific, the above text only provides a general data recovery workflow template. Every data loss situation may turn out unique and it is impossible to create an optimal set of rules to fit every particular case. Common sense and caution should be exercised when performing data recovery. If in doubt, do not hesitate to contact us via Support forum.


ZAR - Before starting checklist

Some conditions do exist which must be met to allow for a successful recovery. Make sure you are not missing something:

1. Check that you have a known-good hard disk with enough free space on it.

WARNING: Never recover data to the damaged drive. Doing so will cause further filesystem damage. It is possible to recover data to a known-working partition on the same physical disk, but it does require special consideration.

2. Check that the system you are working on has the appropriate code pages installed in order to be able to read national-language symbols in file and directory names.

3. Make sure that you understand volume locations. That means you should have clear understanding of the following question: "where is the damaged volume located? what size it was?".

4. When working under Windows NT/2000/XP, you need administrative access to the computer in order to be able to access the disk(s) directly.

5. If physical damage is suspected, review the following settings:

  • Physical drive and partition options - review bad sectors handling and timeouts. Adjust if required.
  • Validation options - you may want to disable validation because it generates additional disk load, which may be undesirable with a damaged disk.
  • S.M.A.R.T. options - review S.M.A.R.T. monitoring settings. Adjust if required.

6. Make sure there is no "hibernation" involved if you are moving undamaged disks around several machines. Ensure the machine is properly shut down before unplugging the good drive from it. This does not apply to the damaged drive. If the drive failed with a system in a hibernated state, attempting to complete a shutdown on it may actually make the things worse, so you should just take the drive as it is.


ZAR - General usage directions

ZAR general execution flow
  • Main window layout
  • Introduction panel
  • Task types
  • Physical device selection
  • Partition selection
    • Scan for missing volumes
    • Manual volume definition
  • Analysis run
  • File explorer
  • File copying
  • Completion

Digital image recovery
  • Image recovery

RAID reconstruction
  • Configuring RAID recovery
    • Defining a RAID manually
  • RAID reconstruction process


ZAR - Main window layout

Main window of ZAR will change during processing, prompting you for more input or indicating the results. However, some fields remain unchanged throughout the recovery run.

"<< Back" and "Next >>" buttons
Pretty much like in any "wizard" interface, "<<Back" button reverts to the previous screen, discarding any input made on the current screen, and "Next>>" button carries out the action as defined on the current screen.

"Help" button
Clicking this button will (obviously) display the ZAR manual.

Status bar entries
The status bar, occupying the very bottom of the ZAR window, displays the following information (left to right order):
  • CPU usage, sampled at five second intervals.
  • Combined device read speed for all operations (if several devices are being read simultaneously, this field displays a sum of the corresponding read speeds), sampled at five second intervals.
  • Disk read cache size.
  • Disk S.M.A.R.T. status, if applicable.


ZAR - Introduction panel

The window displayed when you start ZAR mostly covers the licensing status, plus a handful of helpful links.

Advanced configuration
Opens a preferences dialog, allowing you to fine tune various processing aspects.

Open save file
This button allows you to open previously saved recovery run (note: this feature is not available in the evaluation version).

If no specific configuration is needed, just hit the "Next>>" button for the next step.


ZAR - Task types

Processing modes
Once initial setup is done, you need to specify the task to perform. ZAR utilizes different approaches tailored for the specific task.

Three modes are available

  • "Recover data from a simple volume or from a functional RAID volume" - to be used when reconstruction of the RAID/spanned volume layout is not needed. Typical scenarios include:
    • No hardware or software RAID involved
    • No software RAID involved and hardware RAID is functioning properly
    • Windows 2000/XP/2003 software RAID/spanned volume visible in Disk Management applet of the Management Console (volume should be listed as "online/healthy"; filesystem type readout is irrelevant at this point).
  • "RAID recovery" - to be used when RAID layout information is damaged and needs to be reconstructed.
  • "Image recovery" - specifically tailored to recover photos from a digital camera memory card. Only specific file types (digital images) can be recovered using this mode, and there are some limitations regarding the device type.

Of the above three, you need to select the one matching your situation.

"Erased" versus "Current" files
When ZAR processes the volume, it will encounter multiple files marked as "erased" by the operating system. Two "layers" of data coexist on the crashed volume. There will be files which should supposedly be accessible. We call these "current" files, belonging to the "most current layer" of the data available. On the other hand, there will be files which was routinely deleted before the volume crashed. We call these "erased" files, representing all the "past layers" of the data. ZAR can be configured in three ways
  1. Recover all files (disregarding any marks which may suggest the file was earlier deleted per user's request)
  2. Only recover "current" files - this would attempt to filter the garbage out and only extract the "most current" layer of the data
  3. Only recover "erased" files - useful for mass undeletions, this mode only recovers "past" data.

Special image recovery consideration
The digital camera typically stores all the images in the single folder and thus does not hit the demo (trial) version limit on the number of folders recovered. You may want to try "Simple volume recovery" mode against the memory card. Best yield can be achieved by running both "Simple volume" and "Image recovery" modes, making two passes on the same card, then manually sorting resulting images (you will need to remove duplicate and broken images).


ZAR - Physical device selection

This page lists all the devices available for processing. No specific ordering is enforced. If you do not see the device you need in the list (especially when working with a digital camera memory), try switching access mode in options between "physical" and "logical" devices.

Device ID
This an unique device ID used by ZAR internally to reference this particular device. This ID is used when referencing the device in the log file. Numbering rules1 are provided below.

Model
The device model name and number, if available. If access via logical drives is configured, the drive letter will be displayed along with the model number.

Type
Displays the device type. This can be one of the following:
  • "Fixed" - non-removable device like a built-in hard disk
  • "Removable" - removable device like the USB disk.
  • "Image file" indicates that the device image file is used rather than a physical device.

Capacity
This field displays the device capacity. Missing (or otherwise inaccessible) image files are not removed from the list, but will show a capacity of zero bytes.

Status
Indicates the device self-diagnostic status, if available. There are three possible status values:
  • "OK" - indicates the device is still in at least relatively good shape
  • "Failed" - indicates that the device self-diagnostics has detected some serious failure (e.g. S.M.A.R.T. thresholds are exceeded)
  • "Unknown" - indicates that the device is not capable of self-diagnostics

Disk image files always display "OK" status.

Actions available via popup menu (right click the device in the list)

Device details
Displays information about the device. The following details will be listed if available:
  • Vendor ID
  • Model name
  • Revision
  • Serial number
  • If the device is removable or not
  • If the device supports tagged queuing or not
  • Device attachment bus type
  • If the device is S.M.A.R.T. capable or not.

S.M.A.R.T. status
Displays the dump of the device S.M.A.R.T. information. For more details about interpreting this information, please refer to the S.M.A.R.T. quick reference.

Create image file
Use this function to create the image of the device in the file. "Image file" is just a sector-by-sector copy of the device contents. Bad (unreadable) sectors are replaced with zeros (subject to bad sector handling settings).

Two restrictions apply:

  • You cannot save the file larger than 2GB on the FAT volume. This is because of the limitation of a FAT filesystem (applicable to both FAT16 and FAT32). You thus cannot take an image of the physical disk larger than 2GB and save it on to the FAT volume.
  • You cannot take an image file of the image file. This option will be disabled for image files.

Load image file
Use this function to load previously created image file. You can load the image file created by third-party software if it is in proper format (plain sector-by-sector copy).

Miscellaneous information

Device numbering rules
Device unique identifiers are in the form of XXYY, where XX may be either 01 for a physical/logical (depending on the access method) drive or 02 for an image file. YY is just a sequential number of the device.


ZAR - Partition selection

This page lists all the volumes available for processing. No specific ordering is enforced. Additionally, a special entry may be used to add a volume to the list manually (with an ID of FFFFFFFF).

ID
This is an unique volume ID used by ZAR internally to reference this particular volume. The exact numbering rules are provided below.

System
Operating system type. The filesystem type is displayed based on the available information (which may be discovered damaged later in process). Hence, this field does not necessarily match the filesystem type which will be recovered.

Offset
  • For simple volumes, this indicates the distance from a start of the device to the start of the volume (expressed in megabytes).
  • For RAID/spanned volumes, the volume RAID type will be indicated in this field. For a full layout information, right-click on the volume, then select "Volume Details" in the popup menu.

Size
This field shows the volume size. The total volume size is displayed for a RAID/spanned volume; the size of the individual segments can be viewed via "Volume Details" (same as the above).

Origin
Indicates the method used to get the information about the volume. Five values are possible:
  • MBR/Primary - Volume information is found in the old-style partition table directly (this is the primary partition).
  • MBR/Extended - Volume information is found in the old-style extended partition chain (this is the logical drive in the extended partition)
  • LDM (Dynamic) - The information is derived from Windows 2000 or higher dynamic disks (LDM) database. This volume may be a RAID/spanned.
  • Scan - This entry describes a possible volume found by searching the disk directly (only appears after the scanning for missing partitions)
  • User input - the volume you had specified manually

Actions available via popup menu (right click the volume in the list)

Volume details
Lists the volume information, including
  • Filesystem type
  • RAID/spanned layout type (e.g. RAID0 or RAID5)
  • RAID stripe size, in sectors (always 1 for simple volumes)
  • RAID/spanned volume layout (length, allocation, and order of segments)

Specify the volume manually
Use this option when you do not see the volume you need recovered in the list. More details available here. Once you enter the values as required, program will return to the partition list. The same result may be achieved by selecting a special "Define volume" entry, then clicking "Proceed >>" button.

Scan for missing volumes
Starts an automated search for remains of the volumes on the device (see scanning for missing partitions).

Volume numbering rules
Each volume is assigned the unique ID. This ID is in the form of XXXXYYZZ, where
  • XXXX is a physical device ID (or zero for volumes spanning several devices, like RAID volumes)
  • YY is the volume origin (00 - basic, 01 - dynamic, 02 - volume found by the scan routine, 03 - manually specified)
  • ZZ is the sequential number of the volume


ZAR - Scanning for missing volumes

When a volume is deleted from the partition table, or the partition chain gets corrupt, it will be inaccessible but the corresponding boot sector may remain intact. Partition scan procedure looks through the volume locating such an "orphan" boot sectors. The parameters of the volume are then considered for each of these boot sectors, and the volumes that look reasonably valid are added to the partition view.

To perform a scan, right click anywhere in the partition list, then select "Scan for missing volumes".

Be advised of the two limitations of the process

  • Partition scan might bring up a number of "phantom" volumes. This is because boot sectors are occasionally saved in the data area of the volume (for example, AUTOCHK.EXE Windows NT file system checker contains several boot sector templates in its code). ZAR can not determine if the boot sector is genuine or represents a "phantom" volume, so everything gets shown for your review.
  • RAID or spanned volumes cannot be located this way (with the exception of RAID1 "half-mirror" members), since volume boot sectors do not contain any information about RAID array layout. First member of the RAID or spanned volume (actually containing the boot sector) will typically be found and listed, but attempting the analysis run against the volume defined in such a way will fail.


ZAR - Manually define a volume to be recovered

The process of manually defining the volume seems pretty straightforward. However, there are some tricks involved, depending on the original volume placement.

  • The physical disk containing the single volume is the simplest albeit widespread case. A special option is designed specially for these cases and you should use it when appropriate.

When there are multiple volumes on a physical disk, the following considerations apply

  • The volume is at this stage defined by its two location parameters: offset and size. Offset is a distance from start of a physical disk (sector 0) to the start of the volume (boot sector). It can be expressed either in megabytes or in sectors. Take note that size-based specification (in megabytes) is imprecise (due to the rounding-off errors).
  • When exact data is available, just enter the appropriate values (sector-based) and you're all set.
  • If no exact data is available, compute starting offset by summing up sizes of all the volumes before the damaged one, then subtract 20MB to compensate possible rounding errors. If the result comes negative, use zero instead. Then, enter the resulting value as a starting offset.
  • Increment the volume size by 20MB to compensate starting offset shift, and enter this value as appropriate. If you do not know the volume size precisely, use lower values (for example if the size is around 4.5GB, enter 4400 MB).
  • The placement errors are almost inevitable. It is preferred that you shift the volume towards the "front" of the disk (lower offsets and sector numbers). ZAR does not always honor the boundaries you set, and will trespass them if deemed appropriate, e.g. when following the explicit file reference. However, lower (start) boundary is more "rigid" and has more impact on the recovery results than a higher (start + size, end-of-volume) boundary.

Measurement unit conversions
Unit conversion is influenced by the fact that binary, rather than decimal, numbers are used in computers. Hence the K (kilo) prefix is applied for 1024 units, rather than 1000:
  • 1 KB (kilobyte) = 1024 bytes
  • 1 MB (megabyte) = 1024 KB = 1 048 576 bytes
  • 1 GB (gigabyte) = 1024 MB = 1 048 576 KB = 1 073 741 824 bytes
  • 1 sector contains 512 bytes
  • 1 KB (kilobyte) contains 2 sectors
  • 1 MB (megabyte) contains 2048 sectors


ZAR - Analysis run

This page displays status and progress of the automated analysis. The analysis typically involves the following steps:

  • Raw disk scan, when objects of interest like file or filesystem fragments are identified.
  • Volume parameters detection, mostly computational process deriving several key volume boot sector entries from the data collected during raw scan. Note that even if boot sector is present on the volume, the values will be computed anew anyway. Generally, we do not put much trust into the single data structure on the damaged volume, for doing so will make the process prone to "single point of failure" errors.
  • Parsing the filesystem, during which the final results are generated: file and directory lists are collected and sorted to reconstruct the directory tree.

Please avoid making estimations about the time of processing based on the information displayed, for the following considerations:

  • Presence and location of the bad blocks has an immense effect on the raw scan speed, even if the bad block avoidance is configured in bad sector processing options.
  • Some recovery steps may be computationally and/or memory intensive. ZAR solves quite sophisticated equations to achieve proper recovery. The complexity of these equations depends upon the state of the volume being recovered and the time needed to solve them is thus hardly predictable.

Note that it may take some time to abort the analysis run (either by pressing "<<Back" button or by exiting the application). Delay of up to five seconds even on a decent machine does not indicate a malfunction. The internal state of the software is quite complex and may take quite a long time to clean it up and relinquish any unneeded resources.


ZAR - Directory and file tree view

Note: In the following text, files and directories (folders) are collectively referred to as "objects".

Information shown in the file/directory tree
For a file:
  • Green file icon indicates a "valid" file
  • Red icon indicates an "invalid" file
  • White icon indicates there is no known validation algorithm for this type of file;
  • Gray icon indicates a file not yet processed.
  • Black icon is shown in case there is a physically bad block within a file.
  • File size is displayed after a file name along with the appropriate units.

For a directory:

  • Total size of all contained files.
  • Total number of contained files / Number of "valid" files / Number of "invalid" files (per validation results).

Selection information
This section displays number and size of the selected files. You may want to check the total file size with respect to the free space available on your target drive. It is not unusual to get a slightly larger amount of data than expected. This effect arises when multiple file versions (previously erased files) or duplicate files (e.g. when the file was moved, it may be recovered in both old and new locations) are being restored.

Validation progress and result information
Once the volume tree is shown, background validation process starts to look for "good" and "damaged" files among the repaired. You can proceed to the next step of the recovery (file copying) without waiting for a validation to complete. Once you click "Next>>" button, the validation process is aborted and any pending validation requests are discarded. The validation is not a required stage of the data recovery process.

Actions available via popup menu (right click the directory tree)

Find object / Find next object
Locates and highlights the specified file. Either a full or a partial file name should be specified. Please use wildcards to specify a part of the filename. Simply entering a part of the file name will not work, you need to surround it with asterisks, like "*reports*".

Selection operations
Use this function to modify selection on a set of files without getting into the details about each one. You may specify an exact file name, in which case all files with this name in the appropriate directories will be selected, or you may use wildcards to specify multiple files. Marking file for recovery, clearing the mark, or mark inversion operations can be performed this way.

Important notes:

  • Mass toggle operations only apply to the files contained in the selected directory (and its subdirectories, if any). If there is no directory selected, mass toggle operation is applied to the root directory and thus to all files on the volume.
  • Mass toggle operations are only applied to files. If the directory name happens to match the mask specified, this is ignored (only files are checked).

Show files
When this option enabled (default setting) individual files will be displayed in the volume tree view. The setting does not have any effect except the visual (i.e. validation continues to run in the background).

Show preview
When enabled, the preview for the certain image file formats will be displayed when a file is selected. Preview is currently provided for
  • JPEG images
  • TIFF images


ZAR - Autogenerated object names - DIRxxxx, FILExxx, LostNameXXXX, LostFilesXXXX

During recovery, many partially damaged filesystem objects are located and their reconstruction attempted. Some properties of these objects are typically beyond recognition, and some automatically generated values will be assigned instead. Most common situations are file creation/modification times and file (or directory) names. The following covers common automatic file naming patterns.

What are DIRxxxx and FRGxxxx directories?

These two types are generated on a FAT filesystem. FAT filesystem does not store the directory name inside the directory itself, but puts into the upper-level directory. If the upper level directory gets damaged, there is no way to determine the names for its children (which may still be on the volume somewhere). In such a situation the child directory will be named DIRxxxx.

What are LostFilesXXXX and LostNameXXXX objects?

Opposite to FAT, NTFS does store the object name with the object itself. However, due to the overall complexity of NTFS, additional "abnormal" possibilities emerge, including the perfectly valid file without any name associated with it.

The following two situations occur most often:

  • The file exists on the volume which references some seemingly valid contents, but does not have any name associated with it. However, some name is needed to be able to actually recover a file. So the autogenerated name in the form of LostNameXXXX is assigned to the file.
  • There is a valid file and it has a valid reference to its parent directory. However, parent directory is either missing or damaged beyond recognition. To accommodate the file, the "fake" directory will be created (which does not reflect any real data on the volume) which gets a LostFilesXXXX name. The file will be placed into that directory, and should ZAR encounter any files referencing the same (missing) directory later into the run, they will be placed in their appropriate directory.


ZAR - File copying

Selection information
This section displays number and size of the selected files. You may want to check the total file size with respect to the free space available on your target drive. It is not unusual to get a slightly larger amount of data than expected. This effect arises when multiple file versions (previously erased files) or duplicate files (e.g. when the file was moved, it may be recovered in both old and new locations) are being restored.

Destination directory
Specify the target directory (where recovered files will be placed). You may type the directory name, or browse for it using "..." button. ZAR will check that the path specified does exist and is writeable.

WARNING: Avoid copying data onto the same physical device you are recovering data from. This may induce additional data loss. The following considerations apply:

  • If there is some physical damage involved, any additional load on the disk may cause further damage.
  • If logical structures are corrupt, damage cascading effects may occur during writes on the volume.

Existing files handling
"Overwrite" setting is not recommended for general use because of the following side effect: if there are multiple files with the same name in the same directory (typically several file versions - the latest one plus several previously erased versions), an arbitrary one will be picked, possibly overwriting the good file (with an older version in the above example).

Progress indication
The progress bar displays a percentage of total files size processed. File information displays number of files copied and the name of the file under processing.

"Start copying" button
Obviously, this button starts copying files to the target location.

"Skip current file" button
Forces ZAR to skip the current file. Partial files are not deleted but left on the target.

Flushing the disk cache
Once file copying is finished, the window may appear indicating that disk cache is being flushed. This may take considerable amount of time if "Write cache" setting in options is configured for large write cache and/or you are recovering to a slow target (e.g. over the 10 Mbps network). If you abort the processing by quitting ZAR, the write cache will be discarded rather than written to disk. Some files may remain partially copied, and some will be missing. Thus, it is not recommended that you terminate copy process by quitting the program.


ZAR - Process completion

There is really nothing interesting in this window, except for an (optional) statistics reporting.

Important note: The reporting is optional and as such may be unavailable in your version of ZAR. This has no effect on actual recovery capabilities.

Please take your time to read web reporting explained, then send your report to us by clicking the "Send Report" button. The report is prepared automatically (because we try to avoid bugging you with some stupid questions).


ZAR - Digital image recovery mode

Digital image recovery mode is specifically tailored to recover photographs taken using digital camera. These shots are typically stored on some sort of a small-size, small-capacity removable storage, like Compact Flash memory, Memory Stick, Secure Digital and so on. These storage types are collectively referred to as a "memory card".

Setting up
You need to set the system up in such a way that your memory card is accessible as a disk drive. A setup involving an appropriate card reader device is good for most situations. If you do not have the card reader, or cannot use it for some reason (e.g. camera is using internal non-removable memory), you should try using the camera itself to access the memory card. It may be required that you switch to "Logical drive access mode" in disk access options to achieve proper access (this depends upon the implementation of the camera device driver).

Source (damaged) device and performance considerations
The "image recovery" mode is tailored to work with digital camera memory, which is relatively small. Thus, the following limitation applies:
  • Recovery off the hard disks is not supported1.

1This means we tested and found the results unsatisfactory (i.e. not worth the effort) most of the time.


ZAR - RAID reconstruction settings

General considerations
RAID recovery mode of ZAR 8.4 is used to recover data when the array configuration (such as stripe size, or the order of the array member disks) is lost. If you determine the situation involves RAID reconstruction, select the appropriate mode in Task types. The drives should be accessible as a separate devices. This means you should either connect them to the regular (non-RAIDed) ports, or reconfigure the RAID controller as required to provide access to the drives independently.

Array member disks selection
Select disks which are members of the array. If the array is RAID5 with one disk missing, select all available array members - the missing disk will be reconstructed based on the RAID5 parity data.

Array layout types and stripe sizes
There are three layout types available, namely RAID0, RAID5 "Checkerboard", and RAID5 "MS/LDM". Microsoft Windows 2000/2003 uses "MS/LDM" layout for its software RAID5 arrays.

Stripe sizes are measured in sectors, rather than in kilobytes. Calculation is simple: 1KB = 2 sectors. Maximum stripe size limit is 512 sectors (256KB). Generally, stripe size detection is pretty reliable, so it is recommended that you leave this setting as is. Factory default is minimum 2, maximum 512 sectors.

Input restrictions and recommendations
Generally, search for a RAID0 is cheaper than for a RAID5. Worst case overhead is to search for a RAID5 when there isn't one (parity will be recalculated out of the anticipation that one of the member disks is missing, which is costly in terms of execution time).
  • If you know the array is RAID0, clear all RAID5 derivatives in the "Possible Layouts" box.
  • If one disk is missing from a RAID5 array, mark all the available members of the array. The missing disk will be reconstructed automatically.
  • When not sure to choose either "LDM" or "Checkerboard" RAID5 layout, select both.
  • Avoid ordering to search the drive that was not a member of the array. This is especially important in case of a RAID5, because an additional drive will cause parity recalculation, resulting in even more disks to search, and the algorithm might get lost in all the possibilities.


ZAR - Defining a RAID manually

In case the parameter set is known, it is reasonable to setup the array manually, rather than have a program to perform an automated processing.

Member disks, adding and ordering
First of all, you need to set up array members. This is simply done by adding a disks one by one with an appropriate button. The ordering of drives is significant, so make sure you have it matching the actual order of the disks in the array.

In case one disk is missing from a RAID5, click "Add parity" and the corresponding regenerated drive will be added automatically.

Array components, offsets and sizes
Once the member disks are identified, the location of the data on these disks should be defined. For each member disk, enter two values:
  • Start identifies the LBA on a physical device at which the array data starts.
  • Size is the number of sectors in the array component.

A hardware RAID typically uses the same values across all the member disks.

Array configuration
Parameters in this section control the array address translation. You need to specify the Array Type (be careful not to confuse Checkerboard and LDM variations of a RAID5) first.

For a striped array (RAID0 or RAID5), enter the Stripe Size. Valid sizes are 2, 4, 8, 16, 32, 64, 256 and 512 sectors. For an array which does not stripe data (e.g. RAID1), stripe size of 1 sector should be set.

RAID5 arrays require parity start and rotation defined.

Once you are done with the configuration, click OK. The array you have just specified will be added to the list of the available physical devices and ZAR will switch to the "simple volume recovery" mode.


ZAR - RAID reconstruction process

RAID recovery run
The procedure is fully automated. Expect the following progress indications:

RAID5 parity check

Early into the process, ZAR checks if it needs to reconstruct a missing RAID5 member disk. This only appears if RAID5 was marked as the possible layout.

Scanning disks

During this stage all the array member disks are scanned and the fragments of the filesystem structures and data files identified. These fragments are then used to reconstruct the layout of the array.

Reading sequence numbers

During this stage objects marked as "worth attention" during scan are read again and processed.

Numerical computation in progress

This is displayed when a number-crunching is progressing to determine the stripe size and build hypothesis-tree tables for the next stage to use.

Detecting parameters [various layouts]

During this stage, different hypotheses are tried and their relevance measured.


ZAR - Real-time disk reader settings

Real-time settings adjustment - general considerations
The runtime control panel can be used to adjust disk I/O settings "on the fly". This is useful when processing a drive with a bad sectors. All the changes made to the configuration are in effect for the next I/O operation (i.e. "immediately" for most conditions).

Recommended settings
For a good disk (no bad sectors)
  • "Timeout" - set to 1000 ms.
  • "Retry attempts" - set to 0.
  • "Avoid repeated retries" - enable.
  • "Skip factor" - set to 0.

For a disk with bad sectors

  • "Timeout" - set to 200 ms unless doing RAID recovery. For a RAID recovery, set to 500.
  • "Retry attempts" - set to 1 unless the analysis is unacceptably slow. To increase speed, set to 0.
  • "Avoid repeated retries" - enable.
  • "Skip factor" - set to 32, unless the analysis is unacceptably slow. To increase speed, gradually increase "Skip factor" until satisfactory speed is achieved.

"Force bus reset" should be disabled in most applications, even on a disk with a bad sectors.

Timeout
Controls the amount of time to wait before deciding that a sector is bad. Sometimes a disk device driver does not provide a proper response about read operation status, so any read operation that takes longer than the specified amount of time is considered failed. Note that running some I/O-consuming tasks in the background may result in requests to good sectors exceeding this limit, causing some erroneous markings. The default setting of 1000 ms should fit for most cases when there is no physical damage on the disk. If the disk is physically damaged and scanning it takes a very long time, try decreasing this parameter down to 100 or 200 ms - this should give a significant speed boost.

Retry attempts
This settings controls amount of the additional read attempts once a bad sector is encountered.
  • If set to zero, only one attempt will be made (i.e. the first one fails and then no retries).
  • If "Avoid repeated retries" is set, the additional reads will only be attempted during a first encounter with the particular bad spot. During subsequent encounters, if any, the read error status will be indicated without ever attempting to read the sector.

Avoid repeated retries
If enabled, bad sectors are remembered and subsequent attempts to access the sector already listed as bad return failure without actually accessing the disk. This provides speed improvement on physically bad drives.

Skip factor
Controls how many sectors are skipped (i.e. presumed bad without actually attempting disk access) after one bad sector is encountered while reading the disk. The default value of 1 means for one read error, one entry is recorded in the bad sector list and thus only actual bad sectors are recorded. Setting this to N will result in the following behavior: once a bad sector is encountered, it will be marked as such and never accessed again. Additionally, N-1 subsequent sectors will be marked bad without even checking if they actually are. Use higher settings on hard disks that have excessive physical damage.

Force device/bus reset after a bad sector is encountered
If selected, ZAR will attempt to force a device to reset its state. In case the device reset attempt is unsuccessful, the reset of the entire bus will be attempted. Be advised that a device reset may cause an undesired side effects, because it affects all the devices attached to the bus. The system may experience transient lockups because all the devices attached to the bus are inaccessible while the bus reset is underway.

Forget bad sectors
Clears the previously collected lists of the bad sectors (used to "Avoid repeated retries" as configured) for all devices.

Disk cache sizes
ZAR implements its own disk read and write caches to achieve better performance. Read cache is used throughout the entire recovery run. Write cache is only used during file copying process. The following guidelines apply:
  • If possible, combined size of read and write caches should not exceed total physical memory minus 256 MB.
  • If recovering data from slow media (like ZIP disk or flash memory card), increase read cache size. It would be nice if the whole media can fit into the cache. If needed, decrease write cache size to the minimum to met the above total cache size requirement.
  • If recovery destination is slow (e.g. when recovering to the network drive), reverse logic applies - increase write cache size while sacrificing read cache.

Factory settings are 64 MB read cache and 32 MB write cache, tailored for low-memory applications. Minimums are 16 MB for read and write cache.

Technical - disk read process reference
Once the request is made to read a sector from a physical device, the following happens:
  1. If "Avoid repeated retries" is set, the bad sector list of the device is examined. If the sector is already recorded as bad, further processing is stopped and the error indication is returned.
  2. The cache is examined. If the request can be satisfied from the cache, the data is copied and returned.
  3. The disk read is attempted. If it completes successfully within the specified timeout period, the data is returned.
  4. The read attempt may be repeated if the first one fails. Number of attempts is specified by the "Retry attempts" setting. If successful, the data is returned.
  5. If the requested sector cannot be read, the error indication is returned.
  • Before returning the data, the cache will be updated as required.
  • Before returning the error indication, the address of the bad sector will be recorded in a bad sector list associated with the device. Additionally, "Skip factor" sectors following this bad sector will also be recorded as bad without ever trying to read them. This improves scan speed (because bad sectors are typically grouped close together) with a side effect of discarding some data.


ZAR - Disk Viewer

Direct disk viewing with ZAR
  • Disk Viewer overview
  • Disk navigation
  • Virtual volumes
  • Supported formats
  • Search for text


ZAR - Disk Viewer - Overview

Disk viewer capabilities
The disk viewer is designed to assist a skilled person in assessing the volume condition. It provides search, navigation, and view augmentation for the most common on-disk structure formats. You may found it useful in computer forensics as well.

Important note: the disk viewer does not allow to modify the data. This is by design.

Opening disk viewer
You can invoke the disk viewer by right-clicking the device in the physical devices list, in any of the recovery modes. It is possible and in some cases it is useful to open several viewer windows (e.g. one per drive). To open multiple viewers, just switch back to the main window, then open the additional disk viewer.


ZAR - Disk Viewer - Disk navigation

Moving back and forth
To move through the disk, it is reasonable to use Alt/Shift+Up/Dn keyboard shortcuts. The following logic applies:
  • "Up" means lower addresses (movement towards LBA 0), "Down" means higher addresses (towards the end of the device).
  • Use Shift key to move sector-by-sector. This allows to position to any address.
  • Use Alt key to move object-by-object. Based on the assumption the objects are placed sequentially (which is typically the case for all common filesystem structures), the view shifts by the number of sectors in the current object.

Current location is indicated in the bottom left corner of the window.

Following hotlinks
Some entries can be marked by the dot next to them. This means the entry points to some associated data structure. If you double-click such an entry, ZAR will "follow" that pointer, navigating to its destination.

This "follow" feature depends on the virtual volume definition. The pointers will not be highlighted if no virtual volume is defined, because the destination locations for the links cannot be calculated.

To return to the originating point after examining the data, press Alt+Backspace.

Jumping to the specific address
To navigate to the specific LBA on the physical drive, press Ctrl+G, type in the address, then click OK.

To go to LBA 6, where LDM PRIVHEAD block is located, press Ctrl+L.


ZAR - Disk Viewer - Virtual volumes

The concept
The virtual volume definition is required for ZAR to resolve various references used by the filesystem. Correctly defined virtual volume allows the "Follow" feature of a disk viewer to function, greatly simplifying navigation.

Setting up a virtual volume
Using an existing boot sector (recommended approach)
ZAR can define the virtual volume based on the existing boot sector. This is the most reasonable approach if the boot sector looks undamaged. To do so:
  • Navigate to the boot sector
  • Make sure the appropriate view format is selected (you need data to be presented as a boot sector on screen)
  • Pick "Define a virtual volume" on a "Disk viewer" menu.
  • Click "Import ..." button.

Manual operation
If no boot sectors survived, it is possible to enter the data manually. Pick "Define a virtual volume" on a "Disk viewer" menu, then fill in the data as required.


ZAR - Disk Viewer - Supported formats

Supported on-disk structure formats
  • Partition table
  • LDM database PRIVHEAD and VBLK
  • FAT16, FAT32, and NTFS boot sector
  • FAT16 and FAT32 table
  • FAT16 and FAT32 directory entry
  • NTFS MFT and INDX entries

Supported MFT attributes
  • STANDARD_INFORMATION
  • FILENAME
  • DATA
  • OBJECT_ID
  • VOLUME_INFORMATION
  • VOLUME_NAME


ZAR - Disk Viewer - Search for text

This function locates the next occurrence of a specified text on the disk.

Search for
Enter a text to search for (case sensitive).

Code pages
ZAR can search for the text using several different encodings simultaneously. Select all the options that may apply.
  • ASCII (ANSI Code Page). - Searches for the text as entered.
  • UTF-16 Unicode. - Searches for the Unicode (double-byte) representation of the search pattern
  • Custom code page. - Searches for the search pattern translated into the specified code page.

Notes:

  • on NTFS, file names are stored using Unicode.
  • on FAT, short (8.3 format) file names may be stored using a different (OEM) code page, depending on the system language/locale settings.

At fixed sector offset (hex)
Forces ZAR only to look at the specified offset within a sector when searching. For example it is known that a FAT directory starts with a dot followed by spaces, so it is possible to enter ". " (dot followed by spaces) as a search pattern and use the "fixed offset" option to ensure only sectors starting with this sequence will be found. The hexadecimal value should be specified.


ZAR - Advanced configuration

Advanced configuration options
  • Configuring general options
  • Physical drive and partition options
  • Options common to all filsystems
  • NTFS reconstruction options
  • S.M.A.R.T. options
  • RAID reconstruction options
  • Validation options


ZAR - Configuring general options

Logging

If logging enabled, ZAR logs all significant activity and findings to the specified file. Log format is human-readable plain text, primarily used for troubleshooting data recovery process issues (especially in case of severe damage). Logged items include
  • Hard disk(s) information and status.
  • Partition table and LDM database analysis progress and results
  • Data identification results
  • Filesystem parameters detection progress and results
  • Filesystem structure reconstruction process
  • File validation results
  • Various performance information

Log file can grow as large as 100 MB on large drives - you should place it on the volume with enough free space available. If the disk space is exhausted, log output is silently suppressed.

The following settings are available

  • Logging mode selection. Specifies the number of log files stored.
    • Disabled, no logging - no log file is stored at all.
    • Single file, limited size - all the logs are stored into the specified file; if the file exceeds the preset limit, the contents are erased and log is started anew.
    • Single file - all the logs are stored into single file. The size of that file is not monitored.
    • One log file per session - each time ZAR starts, a new log file is generated, based on the file name you specify and the timestamp.
  • Detail level selection. You should use Normal mode unless explicitly asked to switch to Extended mode by support personnel. Extended mode is here for debugging purposes only.

  • Log file name edit box. Enter the name of a log file there, or browse for a file using the "..." button.

  • Overwrite the log file if it is greater than X MB. When enabled, the existing log file size will be checked and the file overwritten if it is greater than a specified threshold. Note that the log file size is only checked at startup, so it is possible that the log file will grow past the specified limit during the recovery run. In such a case, the log file will be overwritten upon the next launch of ZAR.

Check for an updated version at startup
If enabled, ZAR will connect to www.z-a-recovery.com to check if there is a newer version available. If there is, you will be prompted if you want to download and install the update.

Revert to default settings
Forces the configuration to be reset to the default settings, effective immediately.

Restore hidden notifications and tips

Some of the ZAR notifications can be suppressed by picking "Do not show this message in the future" option in the notification window. This button restores all the previously hidden "hints" and "tips".


ZAR - Options common to all filsystems

Quick scan mode
In certain cases, ZAR can recover a filesystem without a need to perform a full scan off the volume. This may provide significant (up to ten times) speed boost compared to the traditional "read all" analysis.

Quick scan mode activates automatically if certain conditions are met. It works with NTFS volumes only. In case ZAR detects that the data gathered during the quick scan is not enough for a filesystem reconstruction, it will revert to the full scan automatically.

Quick scan mode is inhibited if any of the following conditions are met

  • RAID or Digital Image recovery run is performed
  • The filesystem type override is in effect and the specified filesystem type is other than NTFS

Default setting is Automatic. When set to Disabled, quick scan mode will not activate regardless of the volume condition.

You should disable quick scan mode if you are recovering FAT volume which was accidentally formatted to NTFS.

Cluster factor detection threshold
This is a technical parameter and should be set at 80%. Do not modify it unless explicitly asked to do so by support personnel.

Filter empty files and directories

With this option enabled, empty (sized 0 bytes) files and empty directories (containing no files and subdirectories) will be filtered from the results.

Filter known useless files

Filters out certain files which are known to be of little or no value. The full list of filtered entries follows:
  • ~*.tmp files - various temporary files
  • ~$*.doc - Microsoft Word temporary files
  • ~wrl*.tmp - Microsoft Word temporary files
  • System Volume Information files
  • $MFT, $Boot, $Volume, $Quota and similar NTFS system files.


ZAR - Configuring physical disk access and partition table processing

Disk access method
Controls how devices are accessed. Preferred access method is using physical devices. You should change this setting only if you cannot get your device listed in ZAR. This may apply to some models of USB "key-disks" and flash memory cards (especially when a flash memory card is accessed via the digital camera rather than a card reader device). When "logical drive" method is used, you will not be prompted to select a volume (partition) since each device represents a separate volume. Additionally, loading a disk image file is impossible if access via logical drives is selected.

Check for MBR/LDM information on removable drives
If enabled, ZAR attempts to read and analyze partition table layout on removable drives. Some removable devices (like ZIP disks) do not store this information, so analysis attempt gives bogus if any results. In such a case proceed by using "Manual" partition selection option, and specify that there was only one volume on the disk.

Read and parse LDM (Dynamic Disk) information
LDM (Logical Disk Manager) is a Windows 2000/XP and higher component which implements Dynamic Disks features, including striped, spanned, and fault-tolerant volumes. Its database is read and analyzed to extract dynamic volumes layout. The dynamic disks are not allowed on removable devices and on the laptop computers, hence you may disable this option if this is your case. Additionally, it should be disabled if there are no dynamic disks and physical problems prevent reading of the database.


ZAR - NTFS reconstruction options

MFT fragmentation resolver - background information
The Master File Table (MFT) of the NTFS volume is not contiguous, but is stored in the several fragments. By design of the NTFS, the MFT Mirror (copy of the several critical MFT entries) is stored separately from the rest of the MFT. Thus, at least two fragments of MFT are stored on the volume. More complex layouts are possible due to additional fragmentation (this typically arises the volume gets filled near its capacity). Additionally, several MFT entries may be damaged, thus splitting a contiguous MFT fragment in two.

This fragmentation must be resolved and the contiguous representation of the MFT rebuilt. This is required to

  • recover large and/or heavily fragmented files
  • properly parse and rebuild the directory and file tree

Ignore gaps in MFT up to X entries
In case there is a small gap between MFT entries, it is ignored and data processed as two adjacent parts of the same block. This reduces parser workload at a cost of possible misidentification of the fragments. If the physical damage exists (which contributes to these "gaps"), might be reasonable to increase the value up to the half of the "skip factor" as set in bad sector handling settings. Default value is 2.

Ignore MFT fragments smaller than X entries
If nonzero value is set, small MFT runs will be excluded from the analysis. This reduces parser workload similar to the above. High values can degrade directory tree quality. Recommended value is 16 (default).

Enable NTFS version 1.2 (Windows NT 4.0) compatibility
You may consider disabling this option only if the NTFS volume you're recovering was created (initially formatted) with Windows 2000 or later version. NTFS 1.2 (NT 4.0) and NTFS 3+ (Windows 2000+) use different versions of MFT structures. If the volume was initially formatted with NT 4.0, the later version entries may be missing, thus requiring a different fragmentation resolver algorithm. Disabling this option provides somewhat better performance at a cost of compatibility loss. This option is enabled by default.

Limit NTFS 1.2 resolver table to X K entries
Default setting is 64 K (65536) entries, which should be enough for common cases. Consider increasing this value if you suspect very large number of files and/or directories on the volume. At a total of 500,000 files and directories (combined) it may be worthwhile to increase limit up to 128 K entries.


ZAR - Digital image recovery options

Maximum reasonable image size
Set this to the maximum reasonable size of the image file your camera creates. Any image file larger than that will be trimmed down to the maximum limit allowed. This helps to save time when rendering large images.

End-of-file detection
If it is not possible to determine the exact size of the file during the recovery, initial recovery pass will bring up the files which are larger than original ones. ZAR then attempts to cut the extra data off the files. For this, three methods can be used
  • Image analysis. This one is slowest of all but produces the most precise results. This is the preferred option unless it does not work for some reason or the analysis speed is unacceptably slow.
  • Marker analysis. Faster than image analysis, but less precise and only works with JPEG format. For all other formats, this just disables the file trimming (i.e. same as Leave as is for all files except JPEGs).
  • Leave as is. Disables the automatic trim feature completely. The recovered files will tend to be of excessive size.

Other options (not selectable)
There may be a few of other options on this page, which are locked at certain settings. These are reserved for a future implementation and you cannot change them. This is by design.


ZAR - RAID reconstruction options

When detecting stripe size and member disk ordering, use (either "doublets" or "triplets").
ZAR uses two kinds of patterns to detect RAID parameters - "doublets" and "triplets". "Doublets" are shorter and encountered more often. However, they are less reliable than longer, rarely encountered "triplets". "Doublets" tend to produce more false positives for the algorithm to cope with. Per gigabyte of typical volume, 10 to 20 "triplets" are typically found, which is quite enough to determine the array layout. The same amount of data probably contains about a hundred of "doublets", half of which are misleading. Larger the array, less the need for (and value of) "doublets".

Default setting ("triplets") should be used for any array containing more than five gigabytes worth of data.

Use NTFS MFT entries, if any.
With this option enabled, ZAR will take into account any MFT entries found on the volume. Leave it enabled as per default settings, unless the RAID reconstruction is very slow (possible with an extremely large array, containing more than a million of files and/or directories).

Enable RCRD bias
This should be enabled unless the array reconstruction fails and any of the following conditions is met
  • The filesystem on the array is NTFS formatted to FAT or vice versa (i.e. fragments for both filesystem types are on the array).
  • The filesystem on the array is NTFS version 1.2 (volume formatted by Windows NT 4.0).


ZAR - S.M.A.R.T. monitoring options

Enable S.M.A.R.T. monitoring
If this setting is disabled, S.M.A.R.T. checks will be just skipped altogether. All the devices will be reported as not S.M.A.R.T.-capable even if they do, in fact, support it.

S.M.A.R.T. poll interval
Sets the interval between S.M.A.R.T. status requests, in seconds. Disk status is polled and checked at the end of the interval. Default value of five seconds should fit most applications. Setting lower interval (higher polling frequency) may slow down processing slightly. Increasing the interval is generally acceptable if there is no reason to suspect physical damage of the device.

Pause if temperature exceeds the limit
If the drive temperature exceeds the limit specified, the processing will be paused until the drive cools down on its own. We strongly recommend that you do not increase the default limit of 60 deg C. If temp limit is exceeded too often, consider some cooling improvement (most simplistic approach is to remove chassis cover and use an office fan to blow the air through the chassis; 19 inch stand fan at full speed will do the trick in most cases).

Drive temperature depends upon many factors, the most significant being

  • I/O load. Increasing load causes temperature to rise.
  • Ventilation design, including chassis setup, number and configuration of cooling fans.
  • Power supply unit output. PSU providing excessively high voltage can cause drive electronics to overheat.
  • Ambient temperature. Any heat produced during operation of the drive will ultimately end up dissipated into the ambient air. Effective cooling is not possible if the ambient air itself is hot.


ZAR - Validation options

The validation options are configured here. Typically you do not need to alter default settings (everything enabled), major exception being a physical damage situation. If a physical damage to the drive is involved, you may want to disable the validation by clearing the "Enable background validation of the files". This is done to avoid additional load on the damaged device.

You may want to learn more about validation process.


ZAR - Miscellaneous information

Miscellaneous information
  • S.M.A.R.T. basics
  • Save files
  • Data validation
  • Stats reporting
    • Stats privacy
  • Using wildcards
  • Known file formats


ZAR - Quick guide to understanding S.M.A.R.T. information

S.M.A.R.T. is the abbreviation for "Self Monitoring And Reporting Technology". It is a standard interface protocol and set of the disk features that allows disk to check its status and report it to a host system. S.M.A.R.T. information consists of "attributes", each one describing some particular aspect of drive condition. Some attributes may be designated "life-critical", which implies that the corresponding parameters are more important than other ones.

Three values are associated with each S.M.A.R.T. attribute:

  • "Normalized value", commonly referred to as just "value". This is a most universal measurement, on the scale from 0 (bad) to some maximum (good) value. Maximum values are typically 100, 200 or 253. Rule of thumb is: high values are good, low values are bad.
  • "Threshold" - the minimum normalized value limit for the attribute. If the normalized value falls below the threshold, the disk is considered defective and should be replaced under warranty. This situation is called "T.E.C." (Threshold Exceeded Condition).
  • "Raw value" - the value of the attribute as it is tracked by the device, before any normalization takes place. Some raw numbers provide valuable insight when properly interpreted. These cases will be discussed later on. Raw values are typically listed in hexadecimal numbers.

Most common S.M.A.R.T. attributes reference

Note that not all of the attributes are present on all drives. Some attributes are of similar meaning (just counted differently), so only one of them will normally be monitored by the drive. Some require special sensors (e.g. temperature or G-loads monitoring). The decision about which attributes should be implemented is up to the drive vendor. Along the same lines the interpretation of raw values depends heavily on the manufacturer.

Critical device status attributes
Reallocated sectors count | Indicates how many defective sectors were discovered on the drive and remapped using a spare sectors pool. Low values in absence of other fault indications point to the disk surface problem. Raw value indicates the exact number of such sectors.
Current pending sectors count | Indicates how many suspected defective sectors are pending "investigation". These will not necessarily be remapped. In fact, such sectors my be not defective at all (e.g. if some transient condition prevented reading of the sector, it will be marked "pending") - they will be then re-tested by the device off-line scan1 procedure and returned to the pool of serviceable sectors. Raw value indicates the exact number of such sectors.
Off-line uncorrectable sectors count | Similar to "Reallocated sectors count". Indicates how many defective sectors were found during the off-line scan1.
Read error rate | Logs rate at which specified events (errors) occur. Lower value indicates more events (errors). Retries are not necessarily indicate a persistent problem, but one should proceed with caution if any of these attributes is degraded.
Read error retry rate
Write error rate
Seek error rate
Recalibration retries | Indicates how often the drive is unable to recalibrate at the first attempt. Raw value may show the exact number of recalibration events (at least with some vendors) but this should be taken with a grain of salt.
Spin up time | Low value indicates that a drive takes longer than expected to spin up to its rated speed. Might indicate either a controller or a spindle bearing problem.
Spin retry count | Spin retry event is logged each time the drive was unable to spin its platters up to the rated rotation speed in the due time. Spin-up attempt was aborted and retried. This typically indicates severe controller or bearing problem, but may be sometimes caused by power supply problems.
Drive lifetime information
Drive start/stop count | These two provide the estimation of the drive wear. Vendor estimates the supposed device lifetime and the number of cycles. The value for these attributes is then computed based on this estimation. The T.E.C. condition with one of these attributes does not necessarily indicate a drive failure, but rather suggests that a drive should be considered unreliable due to the wear and tear. Raw values are typically just the count of events.
Power off/retract cycle count
Power on hours count | Normalized values are computed similar to the above. Despite what the name suggests, the raw value of the attribute is stored using all sorts of measurement units (hours, half-hours, or ten-minute intervals to name a few) depending on the manufacturer of the device.
Head flying hours count
Operating conditions information
Temperature | Indicates the device temperature, if the appropriate sensor is fitted. Lowest byte of the raw value contains the exact temperature value (Celsius degrees).
Ultra DMA CRC error rate | Low value of this attribute typically indicates that something is wrong with the connectors and/or cables. Disk-to-host transfers are protected by CRC error detection code when Ultra-DMA 66 or 100 is used. So if the data gets garbled between the disk and the host machine, the receiving controller senses this and the retransmission is initiated. Such a situation is called "UDMA CRC error". Once the problem is rectified (typically by replacing a cable), the attribute value returns to the normal levels pretty quick.
G-sense error rate | Indicates if the errors are occurring attributed to the drive shocking (either due to the environmental factors or due to improper installation). The hard drive must be fitted with the appropriate sensor to get information about the G-loads. This attribute is mainly limited to the notebook (2.5") drives. Once the operation conditions are corrected, the attribute value will return to normal.

1Off-line scan procedure - When the device is idle for some period of time, it may start various self-diagnostic procedures, including just wandering into the surface to read sectors here and there. You may observe this by letting your system idle (provided that no background process requests disk access) and listening to the hard drive. It will soon start to operate "on its own" - this is an off-line scan underway. This is done to detect any possible growing defects before they become critical.


ZAR - Saving and loading states

Disk subsystem considerations
The save file contains certain information about the disk subsystem configuration of the machine performing the run. Should the disk configuration change, ZAR may fail to load the file. Hence, it is recommended to set up the disks as required for the actual recovery before the first attempt.

Autosave
ZAR will save the data gathered during the run to the AUTOSAVE subfolder, created automatically where the program is installed. In case an error occurs during the save the run is continued after an appropriate error message. In such a case you can save the information collected during the run when it is done (when a file and folder tree is displayed, see below).

Autosave feature produces an "abridged" save file, only containing a raw scan data. File and folder tree information is not stored (because it is not known by that time).

Saving state manually
Once the analysis is finished and the file and folder tree is displayed, it is possible to save the analysis results for later reuse. This is done, obviously, by clicking the "Save" button.

Manual save produces a "full" save file, containing all the data available.

Loading saved information
To load a previously saved file, use the "Load saved file" button on the first screen. Provide the location of the file to load when prompted. Three outcomes are possible.
  • Once the "full" save file is loaded, the file and folder tree will be displayed and the background validation starts if enabled in options. The files should then be marked and copied normally.
  • In case the "abridged" save file is loaded, a message will appear stating that the load process was successful and recovery should then be carried as usual. The data will be used automatically.
  • ZAR fails to match the physical device due to the disk configuration change. If it is not possible to continue, various error messages may be emitted and the program will shut down. Typically, there is no workaround in such a situation and the recovery have to be restarted (and disks rescanned).


ZAR - Data validation

Validation - what is it?
Validation of the recovered files is an automated process of checking the files found on the damaged volume in attempt to tell if the particular file is recovered correctly or not. Validator does not know all file types and formats; only a subset of files on volume will thus be tested. However, if many files are validated, the validation result can reasonably well be extrapolated to all the data on volume.

Due to the reasons described below, it is not reasonable to expect "100% correct" validation report even on a perfectly good volume. 95-98% is more reasonable expectation.

Important note
Validation is not available during image recovery process. Image recovery process utilizes some algorithms derived from the validation routines, thus introducing an undesired bias into the validation results.

Limitations of the validation process
  • The most significant is that the validation process can not substitute human review, because there is no way a program can distinguish e.g. between the latest (useful) and older (worthless) versions of the file.
  • On top of that, typical validator does not "truly" read the file. When possible, validator will skim along the file touching and verifying several key points in the file. This is presumed the most fruitful approach because of the following two reasons:
    • Validation of some file formats requires excessive computation effort, which would be impractical unless your other computer is Cray.
    • There are way too many file formats out there. Some of these file formats are fairly complicated. Full-blown reader implementations for all these file formats would just be cost-prohibitive.
  • Some files are in fact a combination of two separate file formats. For example, a self-extracting archive consists of the decompression module executable file immediately followed by the compressed archive data. For such files, the format is checked as specified by the file extension (in the above example the executable module will be checked, rather than compressed data).
  • Some files would be different format from what their extensions suggest. For example, some files left from the older days have .DOC extension but are in fact plain text. The validator may try to verify these files as Microsoft Word format, which is obviously not the case. This will trigger false "validation failure" indication.
  • Not all file formats are supported. Refer to the full list of the file formats supported by the validation engine for details.

That said, the validation result should be taken with a grain of salt as a rough approximation of final recovery quality.


ZAR - Anonymous recovery statistics reporting

Important note: This feature is optional and as such may be unavailable in your version of ZAR. This has no effect on actual recovery capabilities.

Once the analysis run is complete, you will be prompted to send your statistics for our review.

Current version of the report contains the following items, (the following list is in no particular order):

  • Unique random number (see the reporting privacy policy for more details)
  • Software full version
  • Processing mode (i.e. image recovery, regular volume recovery, or RAID recovery)
  • Filesystem type being analyzed
  • Recovery run time
  • Validation results (number of presumably good files, presumably bad files, and the total number of files checked by the validator)
  • Validation process run time
  • Number of errors encountered during validation, if any (for debugging purposes)
  • Name of the file which caused a validation error, if any (for debugging purposes; only one name is recorded, see the reporting privacy policy for more details)
  • Machine hardware specification (physical memory installed, operating system version and patch level)
  • "Missing partition" conditions
  • Task type (i.e. image recovery, file recovery, or RAID recovery)
  • Some technical information regarding decoupled volume parameters calculation (incl. elapsed time and some cross-check data)
  • S.M.A.R.T. redline exceedance information (attribute ID, value and redline for the last occurrence)
  • NTFS $Volume information (filesystem version and clean/dirty status)
  • NTFS MFT fragmentation resolver information (number of fragments, number of purged fragments)

You may preview the report by using "Review report" button.


ZAR - Stats report privacy policy

General considerations
The report you submit is never used separately from others' reports. All the reports collected are subjected to statistical processing, and averages and outliers of the statistics are used for the following purposes:
  • Identify software bugs
  • Identify weak spots in processing algorithms
  • Identify processing speed issues
  • Evaluate various recovery performance aspects and possibly create some neat graphs.

The report does not contain any personally identifiable information and does not contain any sensitive information (like usernames and passwords). There are two things in the report that might require additional explanation in privacy terms.

Random identification number
The random identification number is for us to distinguish between the same error occurring on the same machine (or the data set) hundred times in a row, or occurring once on each of hundred of different machines (data sets). There is no way to trace a random number back to the person who submitted the report (you) or to the particular computer the report was generated on.

File name in the report
Occasionally, a file name may slip into the report. This happens when an abnormal situation is detected within the validation routines. In such a case, the name of the file which caused the error is logged. Only one file name is logged per report, as the parameter named ValErrFile. Typically, a single file name logged does not present a significant concern privacy-wise. On top of that, an error that warrants logging a file name is a rare situation.


ZAR - Using wildcards

You can use wildcards (characters "*" and "?") to specify multiple files in a single operations.

Wildcard "*" matches any number of arbitrary characters, while "?" matches exactly one arbitrary character.

To illustrate: "*.test.??" matches "foo.test.10" and "bar.test.11", but does not match "foo.test.1" or "foo.est.10".


ZAR - List of the file formats supported by validation module

Following is the list of file formats known to the current version of the data validation engine (ZAR 8.4), in no particular order.

  • OLE Structured storage
    • Microsoft Word .doc
    • Microsoft Excel .xls
    • Microsoft Power Point .ppt
    • Windows Installer package .msi
  • .ace archive
  • .arj archive
  • .asf video
  • .dbf database format
  • .exe, .dll, .cpl Windows executable module (Win32/PE format)
  • .gif image
  • .gz gzip archive
  • .ico Windows icon file
  • .inf Windows INF file
  • .jpg, .jpeg JPEG image
  • .mid MIDI sound
  • .mp3 sound
  • .pdf Adobe Acrobat document
  • .png image
  • .qt QuickTime movie
  • .rar archive
  • .rm Real Media
  • .rmid sound file
  • .tga image
  • .tiff image
  • .url Internet Explorer URL file
  • .wav sound file
  • .zip archive


Vairous RAID5 implementation aspects

The theory behind RAID level 5 is simple, but implementations are not. The number of parameters controlling the exact layout is greater than in a RAID 0 and as a result, more variations are possible. Here is a brief discussion of these additional RAID5 parameters (assuming that stripe size and order of member disks in the array is already known).

Parity placement
Let's first consider parity location. Parity should be distributed evenly across member disks, which leaves us with two parameters:
  • Starting disk number - a number of disk containing parity at row 0 (at the very start of the array). Most typical implementation is to put the first parity block into the end of the row (last column). This is shown in the example below (parity starts at Disk 2 in both examples).
  • Rotation - an increment value applied to the number of the disk containing parity when writing a new row. Typical values are either +1 (to the right, forward layout) or -1 (to the left, inverted layout).

Parity placement examples: Forward and inverted layouts

Parity placement examples: forward and inverted layouts, parity starts at Disk 2 in both cases.

Once the parity has been placed, we then need to define how the data is distributed (data interleaving rule). Two widespread approaches are discussed below.

Placing data - checkerboard layout
In a "checkerboard" layout, data is placed into the array blocks (stripes) left-to-right, skipping parity. Two examples of the resulting placement are provided below:

Placement of the adjacent blocks is worth some discussion. In the 3-disk forward checkerboard layout it is possible that adjacent data blocks are placed on the same physical disk, effectively doubling the stripe size - see blocks 8/9, 14/15 on the upper left chart. This may cause undesired performance hit.

Placing data - Microsoft (LDM) layout
Windows 2000 and higher (or, more precisely, the Logical Disk Manager - LDM - component) uses more sophisticated algorithm to place data to achieve better block spacing. The process of selecting what goes where is best described in two steps:
  1. Write parity into the first column of the array, followed by the data blocks in ascending order.
  2. Rotate the rows until parity "slips" into its place.

This results in ordering different than a "checkerboard" layout, as illustrated below:

LDM RAID5 parity and data placement

Please note that "forward LDM" layout results in minimum distance between blocks in the same column, which is not very efficient performance-wise. So it is not used. Contrary to that, an "inverted LDM" layout gives the largest possible difference between two blocks in the column (equal to the number of the array member disks). This layout is used by Windows to achieve maximum performance of the RAID5 array. The net result is as follows:

Detecting an array layout automatically

Human being can solve the problem easily (especially thinking about an experienced human being) by looking at the overall picture of the broken array. The automated software lacks the human perception and has to utilize different approaches. Automated approaches mostly rely on some statistical properties of the array. This imposes some requirements as far as broken array is concerned.

  • Arrays containing large amounts of data are easier to reconstruct because they contain more samples for a statistics.

  • Arrays with more drives require more data (for more samples)

  • RAID5 is more complicated because it has more parameters (layout type and parity parameters are to be determined).